home *** CD-ROM | disk | FTP | other *** search
/ Night Owl 19 / Night Owl (The Best of Shareware)(NOPV 19)(1996).ISO / 018a / elrul512.zip / PKEYDROP.RUL < prev    next >
Text File  |  1995-05-31  |  6KB  |  155 lines
  1.  
  2. --- Following message extracted from PKEY_DROP @ 1:374/14 ---
  3.     By Christopher Baker on Wed May 31 20:40:26 1995
  4.  
  5. From: Christopher Baker
  6. To: All
  7. Date: 17 May 95  18:28:50
  8. Subj: PKEY_DROP Echo Guidelines - regular repost
  9.  
  10. -----BEGIN PGP SIGNED MESSAGE-----
  11.  
  12. This is the PKEY_DROP Echo. The purpose of the Echo is to provide a place
  13. to post and find public-keys for data privacy and electronic signatures
  14. within FidoNet.
  15.  
  16. This is a companion conference to PUBLIC_KEYS Echo. It is distributed via
  17. the same channels as PUBLIC_KEYS. It is not intended for general message
  18. traffic but questions relating to public-key problems and bogus key notices
  19. are permitted. Simply identify and drop your personal public-key into this
  20. Echo and conduct any general discussion in PUBLIC_KEYS Echo. Keyrings are
  21. NOT permitted to be posted here. Please do not post keyserver reports
  22. here. Multiple personal keys are permitted.
  23.  
  24. This is a technical Echo with very few rules. Those very few rules are:
  25.  
  26. 1. Stay on-topic. Public-key posts are the main purpose and notice of
  27.    key problems or bogus keys is the secondary purpose.
  28.  
  29. 2. ONLY personal public-keys are to be posted here. Keyrings MAY NOT
  30.    be entered into the Echo. If anyone wants a keyring, they can go
  31.    file-request one from an appropriate source.
  32.  
  33. 3. No Private flagged messages in Echomail! Encrypted traffic as
  34.    public-keys is permitted because that is what this Echo is for.
  35.    User-specific encrypted traffic is not permitted since it defeats
  36.    the purpose of Echomail.
  37.  
  38. 4. Clear-signing a key post adds an additional layer of processing and
  39.    is not necessary. Please consider your audience when deciding to
  40.    clear-sign a key post.
  41.  
  42. 5. Be aware that Echomail is NOT secure. Don't take anything at face value.
  43.  
  44. 6. The posts in this Echo are the sole responsiblity of the poster. If you
  45.    need verification, use Netmail.
  46.  
  47. 7. The Moderators will deal with off-topic traffic. Don't respond for them.
  48.    Links to this Echo will only be curtailed when absolutely necessary so
  49.    please don't make it necessary. [grin]
  50.  
  51. The Moderators are Christopher Baker [KeyID: 1024/F89A24F9 1994/05/18]
  52. and GK Pace [KeyID: 1024/EE38FB41 1994/05/14] at 1:374/14 and 1:374/26,
  53. respectively.
  54.  
  55. This Echo is Gated into Zone 2 by Jens Mueller at 2:24/24 who sends it on
  56. to Harry Bush at 2:51/2. Consult either Jens or Harry for Zone 2 feeds. The
  57. Echo is gated into Zone 3 by Jackson Harding at 3:800/857. [thanks, guys!]
  58.  
  59. The other Zones are open [hint, hint].
  60.  
  61. KEYNOTES:
  62.  
  63. ONE-
  64.  
  65. If you have generated a public-key of 1024 bits with 2.3a or later
  66. versions of PGP, you probably don't need to revoke the old one and make
  67. a new one. This is particularly true if your key was made with any of
  68. the 2.6 generations. If you're worried about getting 2.6.2 or later on
  69. your key, don't make a new one, just re-export your public-key with the
  70. newer version of PGP using the standard key export command:
  71.  
  72. PGP -kxa youruserid youruserfilename
  73.  
  74. and then copy the new copy of your public-key to your file directory so
  75. people can file-request or download it.
  76.  
  77. TWO-
  78.  
  79. MAKE SURE you distribute the PUBLIC-KEY ONLY! Every so often a neophyte
  80. will put his/her secret-key into circulation. That's BAD!
  81.  
  82. THREE-
  83.  
  84. When making your first public-key pair or a new public-key pair, go for
  85. the 1024 bit size. Don't make your key any more vulnerable than you need
  86. to regardless of how long it takes to compile it. If you go for the 2K
  87. size key, keep in mind that 2047 bits is NORMAL.
  88.  
  89. FOUR-
  90.  
  91. MAKE SURE you put all your possible userids on your public-key after you
  92. generate it and before you circulate it for use and/or signatures. It is
  93. especially important to be sure that your standard User Name is on there
  94. EXACTLY as it appears in the From: line on your Netmail and Echomail.
  95. This makes it much simpler for folks to encrypt to your name as detected
  96. in a reply.
  97.  
  98. It also makes life simpler if your Netmail name, your public-key name
  99. and your FidoNet Nodelisting name are all the SAME name! 
  100.  
  101. FIVE-
  102.  
  103. It is recommended that individual, public-keys be made available via Netmail
  104. or by file-request with the magic filename: PGPKEY and that the public-key
  105. provided for that request by given a distinctive filename using part or all
  106. of each provider's name and address. For example, on my system, a
  107. file-request of PGPKEY will give BAK37414.ASC to the requesting system. A
  108. magic filename of KEYRING will yield extracts from my Public Keyring as
  109. BAKPUB14.ASC. This will avoid duplicate overwriting and make it easier to
  110. track the keys. Using standard magic filenames will make it easier to find
  111. keys and keyrings on different systems.
  112.  
  113. SIX-
  114.  
  115. DO NOT SIGN someone's public-key UNLESS you have obtained it directly 
  116. from them or their system under password or by direct file-request. 
  117. Signing the keys of others without knowing those keys came from who they 
  118. claim to be from dilutes the web of trust. You do not have to sign a key 
  119. to add it to your keyring.
  120.  
  121. SPECIAL NOTE ---
  122.  
  123. If you lose your secret-key password [or forget it] or your secret-key in a
  124. drive crash [because you failed to back it up on floppy], you cannot issue a
  125. revocation certificate. In that case, you should make a general announcement
  126. in all related Echos that your old key should be disabled using the PGP
  127. disable command [PGP -kd userid] for your userid. That keeps your useless
  128. key on their keyrings [so they won't be replaced from other lists who didn't
  129. get the word] and permits them to add a new key from you without one
  130. interfering with the other. BACKUP! BACKUP! BACKUP! [clear?] [grin]
  131.  
  132. This Echo is available on the Zone 1 Backbone. This Echo was Elisted
  133. as of ELIST211. Please feel free to announce this Echo to all interested
  134. participants in your area.
  135.  
  136. Thanks.
  137.  
  138. TTFN.
  139. Christopher Baker & GK Pace
  140. Moderators
  141.  
  142. -----BEGIN PGP SIGNATURE-----
  143. Version: 2.6.2
  144. Comment: SUPPORT the Phil Zimmerman Legal Defense Fund!
  145.  
  146. iQCVAwUBL7p4lcsQPBL4miT5AQFEWwP+IwEOLvZE5IXKYs5fLQqSFcdILPgbZxSn
  147. xMH+XdAFBNlfrFiJJwSyrARvXF80UnURODW4V2lpaAdU4MJx8nvz35urAGGYttZ4
  148. EG+VWu9+aI0vrO94VfLp8OfMoREjNE01s2bJJBsecboQx0y8JP0REpKmjliUQ+T6
  149. aeLSmc5ZQIE=
  150. =rxr0
  151. -----END PGP SIGNATURE-----
  152.  
  153. --- GenMsg [0002] (cbak.rights@opus.global.org)
  154.  * Origin: Rights On! for Privacy! It's a Right not a privilege! (1:374/14)
  155.